Transaction device and method for securing a transaction between the transaction device and an external device

ABSTRACT

A transaction device for securing a transaction includes an NFC controller, a communication interface, an application processor, a display and a user input device. The NFC controller is configured to receive, via a contactiess NFC interface, data related to the transaction from an external device. The communication interface is configured to receive an application program for the transaction device. The application processor is coupled to the NFC controller and configured to process the application program. The display is coupled to the application processor and configured to display transaction information. The user input device is linked to the NFC controller and configured to receive a user acknowledgement of the transaction. The NFC controller is further configured to transmit, via the contactless NFC interface, a transaction agreement of the transaction to the external device in response to the user acknowledgement from the user input device, without the user acknowledgement and the transaction agreement being routed through the application processor.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of copending U.S. patent applicationSer. No. 12/534,944 filed Aug. 4, 2009. This application also claims theright to foreign priority under 35 U.S.C. Section 119 from FrenchApplication No. 08 04450 filed in France on Aug. 5, 2008. Thedisclosures of the two above-identified applications are bothincorporated herein by reference.

BACKGROUND OF THE INVENTION

Embodiments of the present invention relate to a transaction device forperforming a transaction with an external device through a communicationlink.

Embodiments of the present invention also relate to a method forsecuring a transaction between a transaction device and an externaldevice, in particular a transaction made with a programmable portabledevice.

Nowadays, transactions can be performed using conventional portabledevices such as, for example, mobile telephones, personal digitalassistants (PDAs), or the like. In fact, wireless or contactlesscommunication technology can easily be embedded in such portable devicesfor the establishment of wireless or contactless communication with anexternal device in order to perform transactions.

FIG. 1 shows an example of a conventional transaction device 1 with NearField Communication (NFC) communication capabilities. Essentially, thetransaction device includes an NFC communication controller 10, anapplication processor 20, a display device 31, and an input device 32linked to the application processor 20.

The NFC communication controller 10 includes an antenna coil that allowsa contactless data link CDL to be established with an external NFCdevice 40, which can be, for example, a payment terminal, a cashmachine, or the like. The external device 40 is also equipped with anantenna coil and both the external device and the NFC communicationcontroller can exchange data by inductive coupling.

Inside the transaction device 1, the communication controller 10 iscoupled with at least one data and program memory 11, in which a programexecuted by the controller 10 is stored. The application processor 20 iscoupled with at least one data and program memory 21 in whichapplication programs are stored.

Additionally, the transaction device 1 typically includes anothercommunication interface 22 through which it can receive applicationprograms APP which are stored in memory 21 and executed by theapplication processor 20. It is assumed here that at least oneapplication program APP has been downloaded to manage a transactionthrough the contactless data link CDL.

By nature, such a conventional portable device is much less secure thana certified and secured payment device, such as those found in shops orbanks. In particular, the application processor 20, in which applicationprograms APP can be downloaded and installed using the communicationinterface 22, may contain malicious software. This malicious softwarecan be designed to intercept or corrupt transaction data in paidapplications, such as payment of a restaurant bill, withdrawal of moneyfrom a cash machine, payment for access to a specific location (e.g,subway, museum, nightclub, or the like), or the like. Consequently, sucha corruption of transaction data may lead to the payment of an amountgreater than that expected by the user.

For example, a transaction may be initiated and a connection (data linkCDL) may be established between the transaction device 1 and theexternal device 40. The external device 40 sends the transaction data tothe transaction device 1. The amount is displayed on the display device31 and the user is then prompted to confirm acceptance of payment of theindicated amount of money by entering an acknowledgement through theinput device 32 (for example, by selecting “Yes” or “No,” by entering apersonal code as an acknowledgment, or both). The application processorthen forwards this acknowledgment to the external device 40 in order tocomplete the transaction. Malicious software may corrupt the applicationprogram APP so that the transaction is performed with transaction datathat is different from the data displayed to and/or accepted by theuser. As an example, a transaction for an amount of 1000

may be initiated by the malicious software, whereas an amount of 10

is displayed to the user. In this case, 1000

are actually paid instead of the 10

that the user accepted to pay.

Therefore, it is desirable to provide a method for securing atransaction made with a transaction device that may be corrupted bymalicious software, in particular a transaction made with a conventionalprogrammable portable device.

BRIEF SUMMARY OF THE INVENTION

One embodiment of the present invention relates to a method for securinga transaction between a transaction device and an external device. Thetransaction device includes a communication controller, an applicationprocessor, and an input device. The transaction includes the exchange ofapplication data between the transaction device and the external device,and the transmission of transaction data from the transaction device tothe external device or from the external device to the transactiondevice. The method of securing the transaction includes requiring a userto enter agreed transaction data via the input device, monitoring thetransaction data designated to be sent to the external device orreceived from the external device, and preventing the transaction datafrom being sent to the external device if the transaction datadesignated to be sent is different from the agreed transaction data, orrejecting the received transaction data if the received transaction datais different from the agreed transaction data.

According to one embodiment, the method includes interrupting thetransaction rather than preventing transaction data from being sent orrejecting received transaction data.

According to one embodiment, the method further includes capturing andstoring by the communication controller the agreed transaction dataentered by the user, monitoring by the communication controller thetransaction data designated to be sent to the external device orreceived from the external device, and configuring the communicationcontroller to refuse to send transaction data designated to be sent thatis different from the agreed transaction data, or rejects receivedtransaction data that is different from the agreed transaction data.

According to one embodiment, the method further includes applying to thecommunication controller a command requesting the communicationcontroller to capture and memorize the agreed transaction data beforerequiring the user to enter agreed transaction data.

According to one embodiment, the method further includes applying apredetermined command to the communication controller when transactiondata is to be sent to the external device, providing the communicationcontroller with the transaction data designated to be sent, configuringthe communication controller to monitor the transaction data in responseto the predetermined command, and sending the transaction data with oneof predetermined encapsulation data and predetermined accompanying dataif the transaction data designated to be sent is identical to the agreedtransaction data.

According to one embodiment, the method includes configuring theexternal device to reject transaction data that is not one ofencapsulated with the predetermined encapsulation data and accompaniedwith the predetermined accompanying data.

According to one embodiment, the method further includes sendingapplication data to the transaction device using a predetermined dataframe, in response to the reception of the predetermined data frame,comparing the transaction data present in the predetermined frame to theagreed transaction data via the communication controller.

One embodiment of the present invention relates to a communicationcontroller, an application processor to perform transactions with anexternal device through the communication controller, and an inputdevice. The transaction device is configured to require the user toenter agreed transaction data via the input device in the course of atransaction, monitor the transaction data designated to be sent to theexternal device or received from the external device, and prevent thetransaction data designated to be sent from being sent to the externaldevice if the transaction data designated to be sent is different fromthe agreed transaction data, or to reject the received transaction dataif the received transaction data is different from the agreedtransaction data.

According to one embodiment, the transaction device is configured tointerrupt a transaction when the transaction data designated to be sentis different from the agreed transaction data, or when receivedtransaction data is different from the agreed transaction data.

According to one embodiment, the communication controller is configuredto capture and store the agreed transaction data entered by the user,monitor the transaction data designated to be sent to the externaldevice or received from the external device, and refuse to sendtransaction data designated to be sent that is different from the agreedtransaction data, or reject received transaction data that is differentfrom the agreed transaction data.

According to one embodiment, the application processor is configured torequire the user to enter agreed transaction data, and to apply to thecommunication controller a command requesting the communicationcontroller to capture and store the agreed transaction data beforerequiring the user to enter the agreed transaction data.

According to one embodiment, the application processor is configured toapply a predetermined command to the communication controller whentransaction data is to be sent to the external device, and to providethe communication controller with the transaction data designated to besent. The communication controller is configured to monitor thetransaction data in response to the predetermined command, and send thetransaction data using one of predetermined encapsulation data orpredetermined accompanying data if the transaction data designated to besent is identical to the agreed transaction data.

According to one embodiment, the communication controller is configuredto, in response to the reception of a predetermined data frame includingtransaction data, compare the transaction data present in thepredetermined data frame to the agreed transaction data.

According to one embodiment, the communication controller is an NFCcontroller.

According to one embodiment, the application processor is one of abaseband processor of a mobile phone and the main processor of aPersonal Digital Assistant.

One embodiment of the present invention relates to a transaction system,comprising a transaction device as described above and an externaldevice configured to perform a transaction with the transaction device.

According to one embodiment, the external device is configured to refusetransaction data that is not one of encapsulated with predeterminedencapsulation data and accompanied with predetermined accompanying data

According to one embodiment, the external device is configured to sendapplication data to the transaction device using a predetermined dataframe.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

The foregoing summary, as well as the following detailed description ofthe invention, will be better understood when read in conjunction withthe appended drawings. For the purpose of illustrating the invention,there are shown in the drawings embodiments which are presentlypreferred. It should be understood, however, that the invention is notlimited to the precise arrangements and instrumentalities shown.

Embodiments of the present invention will be described in greater detailin the following description, in connection with, but not limited to,the following figures:

FIG. 1 is a schematic block diagram of a conventional transactiondevice;

FIG. 2 is a schematic block diagram of a transaction device according tocertain preferred embodiments of the present invention;

FIGS. 3A-3B are simplified flowcharts describing a method for securing atransaction according to a first embodiment of the present invention;

FIG. 4 is a simplified flowchart describing a method for securing atransaction according to a second embodiment of the present invention;

FIG. 5 is a simplified flowchart describing a variant of the methodsshown in FIGS. 3B and 4;

FIGS. 6A-6B are simplified flowcharts describing a method for securing atransaction according a third embodiment of the present invention; and

FIG. 7 is a schematic block diagram of a transaction device according tocertain other preferred embodiments of the present invention.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 2 shows schematically, in block form, a transaction device 2according to an embodiment of the present invention, for example amobile phone or a PDA. Similar to the transaction device 1 describedabove in connection with FIG. 1, the transaction device 2 includes acommunication controller P1 and at least one application processor P2.The communication controller P1 is, for example, an NFC controller withan antenna coil able to send and receive data through a contactless datalink CDL to and from an external device ED. The external device ED canbe any type of NFC user-interaction portal and is also equipped with anantenna coil. The communication controller P1 is coupled with at leastone data and program memory PMEM1 in which a program executed by thecommunication controller is stored. Likewise, the application processorP2 is coupled with at least one data and program memory PMEM2, and canbe, for example, the baseband processor of a mobile phone, the mainprocessor of a PDA, or the like. Other host processors, not shown, suchas a Subscriber Identity Module (SIM) or other secured element may beincluded in the transaction device and connected to the communicationcontroller P1.

The transaction device 2 also includes a display device DD and an inputdevice ID which are linked to the application processor P2. The inputdevice ID can be, for example, a keypad, a microphone, a biometricinput, a combination of these elements, or any other similar deviceallowing a user to input information.

Additionally, the transaction device includes at least one communicationinterface, such as a wireless interface (Wi-Fi), a radio interface ofthe Global Standard for Mobile Communications (GSM)-type, a UniversalSerial Bus (USB) port, an Ethernet port, or the like, or a combinationof these elements that are schematically represented as a communicationinterface CI of the application processor 20. Through this interface CI,the transaction device 2 can receive application programs APP that arestored in memory PMEM2 and are executed by the application processor 20.

As indicated above, an application program may contain malicioussoftware designed to corrupt transaction data.

On the other hand, it is known that memory PMEM1 is incorruptible bymalicious software as it is programmed in the factory and is notuser-accessible. Embodiments of the present invention are based on thisobservation, and rely on the communication controller P1 to verify thattransaction data exchanged between the application processor P2 and theexternal device ED are not corrupted.

According to one aspect of embodiments of the present invention, thecontroller P1 is also linked to the input device ID so that it can alsocapture data entered by the user. For example, both the input device IDand the application processor P2 can include a Universal AsynchronousReceiver/Transmitter (UART) interface I1, I2 respectively, that areinterconnected by means of two wires Tx, Rx. In this case, thecommunication controller P1 also includes a UART interface I3 that isconnected to at least the Rx wire of interface I1, in order to receivedata emitted by the input device ID.

According to a second aspect of embodiments of the present invention,when a transaction involving transaction data is performed the user isrequired to enter the transaction data, for example the amount of moneythat the user wishes to pay, which will hereinafter be designated“Agreed Transaction Data” AGT.

According to a third aspect of embodiments of the present invention, thecommunication controller P1 is configured to monitor transaction data TDsent to the external device ED or received from the external device, andto intervene in the transaction being processed if such transaction dataTD is different from the agreed transaction data ATD that was entered bythe user. The “intervention” of the communication controller may includeinterrupting of the transaction, refusing to send data to the externaldevice, or the like, and generally speaking, performing any action thataims to protect the user from transactions involving transaction datathat is different from the transaction data agreed by the user.

Different implementation examples will now be described with referenceto FIGS. 3A, 3B, 4, 6A, and 6B.

In these embodiment examples, the controller P1 receives incoming dataframes IDF that are in a format of the type “{x[IAD]x}” from theexternal device ED, wherein IAD is incoming application data to theattention of the application processor P2 and “x” is encapsulation dataused by the communication controller P1 and the external device ED tomanage the communication. For example, encapsulation data may include aStart of Frame (SOF), an End Of Frame (EOF), NFC commands, CyclicRedundancy Check (CRC) signature, or the like. Incoming application dataIAD, included in incoming data frames IDF, is de-encapsulated by thecommunication controller P1 and supplied to the application processorP2.

Likewise, the controller P1 sends to the external device ED outgoingdata frames ODF in a format of the type “{x[OAD]x}” wherein OAD isoutgoing application data and “x” is encapsulation data. Outgoingencapsulated application data OAD is supplied by the applicationprocessor P2 to the communication controller P1 by means of commands ofthe type SEND_DATA [OAD].

For simplicity, the communication controller will be called “P1”, theapplication processor “P2”, and the external device “ED”. An incomingdata frame will be called an “IDF” and an outgoing data frame called“ODF”; incoming application data will be called “IAD” and outgoingapplication data “OAD”. Agreed transaction data will be called “ATD”.

FIG. 3A is a simplified flowchart describing processing steps performedby P1 in the course of a transaction. One can observe differentprocessing loops:

-   -   a processing loop L01 including steps S01 and S02,    -   a processing loop L02 including steps S03 and S04,    -   a processing loop L03 including steps S05 and S06, and    -   a processing loop L04 including steps S07 to S11.

Loops LOT and L02 include conventional processing steps and loops L03and L04 are provided to implement aspects of embodiments of the presentinvention. These processing loops are linked to an initial wait step S00in which the controller P1 waits for an incoming data frame IDF from theED or for a command from P2.

The processing loop L01 is performed when P1 receives an IDF from theED, i.e., encapsulated incoming application data {x[IAD]x}, in step 01.P1 then de-encapsulates the IAD and sends the IAD to P2 in step 02.

The processing loop L02 is performed when P1 receives a commandSEND_DATA [OAD] from P2, in step S03. P1 then sends to the ED an ODFincluding the encapsulated OAD {x[OAD]x}, in step 04.

The processing loop L03 is performed when P1 receives a specific commandATDR (“Agreed Transaction Data Request”) from P2, in step S05. Thiscommand informs P1 that P2 will prompt the user to enter the ATD usingthe input device ID. In response to this command, P1 monitors the inputdevice ID, then captures and stores the data supplied by the inputdevice ID as agreed transaction data ATD entered by the user.

The processing loop L04 is performed when P1 receives from P2 a specificcommand SEND_TD [TD] including transaction data TD, in step S07. Thiscommand requires P1 to send to ED a specific ODF in a format of the type{y[TD]y} or {y[TD]x} or {x[TD]y} wherein “y” is encapsulating data thatis different from the usual “x” encapsulation data.

When such a command is received, P1 first checks whether ATD has beenstored (step S08), that is, whether the processing loop L03 has alreadybeen performed. Two situations can occur:

1) If P1 does not contain stored agreed transaction data ATD, thereceived command SEND_TD is regarded as suspect and is rejected.Moreover, if a higher level of security is desired, the reception ofsuch a command when no agreed transaction data has been stored can beconsidered as an inacceptable breach in the security of the transactionand consequently P1 can be configured to cause a complete interruptionof the transaction instead of merely rejecting the command. Thus, P1goes to step S10 in which it sends to P2 information indicating that itrefuses to send the ODF containing the non-agreed transaction data TD orin which it completely interrupts the transaction. P1 then returns tothe wait step S00.

2) If the agreed transaction data ATD has been stored, P1 verifieswhether the ATD and the transaction data TD in the command areidentical. If the data are not identical, P1 goes to step S10 toindicate to P2 that it refuses to send the ODF containing the non-agreedtransaction data TD or else interrupts the transaction. P1 then returnsto the wait step S00. If the agreed transaction data ATD and thetransaction data TD are identical, P1 sends the ODF to the ED in theform {y[TD]y} or {y[TD]x} or {x[TD]y}, then returns to step S00.

Those skilled in the art will note that an additional security mechanismcan be provided in the external device ED so as to ensure that notransaction data TD will be accepted if it is not encapsulated in a dataframe containing the specific “y” encapsulation data. In anotherembodiment, it may be provided that the terminal ED generates a randomvalue or “token” at the beginning of a transaction and forwards it toP1, and that transaction data are accepted by the ED only if thetransaction data is accompanied by this “token”.

FIG. 3B is a simplified flowchart describing processing steps performedby P2 in the course of a transaction, these steps correspond to thesteps described above in connection with FIG. 3A. Steps S20 to S27 areshown. In step S20, P2 waits for incoming application data IAD, which istransmitted by P1 after de-encapsulation (step S02 in FIG. 3A) from theED. When IAD is received, P2 goes to step S21 in which P2 analyzes theIAD and checks whether transaction data TD is required by the ED. Twosituations can occur:

1) If at this step of the transaction no transaction data is requestedby the ED, P2 goes to step S22 in which it processes the IAD and formsoutgoing application data OAD to the attention of the ED. Suchprocessing of the IAD, until the formation of the OAD, may includedifferent sub-steps that are not shown for the sake of simplicity. Inparticular, these sub-steps may include displaying different informationand/or data to the user via the display device DD and capturing dataentered by the user via the input device ID. Insofar as the data enteredby the user is not sensitive transaction data TD, it is not necessarythat P1 be involved in this processing. In step S23, P2 sends thecommand SEND_DATA [OAD] to P1 (which is handled by P1 in steps S03, S04in FIG. 3A). P2 then returns to the wait step S20.

2) If the IAD contains a request for transmitting transaction data TD,P2 goes to step S24 in which it sends the command ATDR to P1 (comparestep S05 in FIG. 3A). P2 then proceeds to step S25 in which it uses thedisplay device DD to prompt the user to enter the agreed transactiondata ATD. In step S26, which occurs simultaneously to step S06 in FIG.3A, P2 monitors the input device ID, then captures and stores the agreedtransaction data ATD. In step S27, which corresponds to step S07 in FIG.3A, P2 sends the command SEND_TD [TD] to P1. Transaction data TDincluded in this command is assumed to be the agreed transaction dataATD entered by the user. If malicious software in the program memoryPMEM2 of P2 tries to corrupt the transaction data present in the SEND_TDcommand, the communication controller will detect the corruptedtransaction data in step S08 or S09 in FIG. 3A.

The transaction process described above includes a confirmation of thetransaction data by the user in step S25. FIG. 4 is a simplifiedflowchart representing processing steps performed by P2 in a method forsecuring a transaction according to a second embodiment of the presentinvention. This flowchart is identical to the flowchart of FIG. 3B,except that step S21 and step S25 are replaced by step S21′ and stepS25′ respectively. In this embodiment, the ED simply requests that theuser indicate the amount of the transaction data involved in the currenttransaction. This may occur, for example, when the transaction device isused to withdraw money from a cash machine without requiring the user toenter the amount of money to be withdrawn on an input device of the cashmachine. In this case, the input device of the transaction device isused as the input device of the cash machine. Thus, in step S21′ the IADreceived by P2 simply contains a request requiring that the transactiondata involved in the transaction be communicated to the external deviceED. In step S25′, P2 prompts the user to enter the desired transactiondata instead of prompting the user to confirm the transaction data.

It will be apparent to those skilled in the art that different variantsof the above-described embodiments can be envisaged. For example, asshown in FIG. 5, the processor may return to the wait step S20 afterhaving captured the ATD in step S26, instead of going to step S27. Inthis case, steps S24-S26 may be performed in advance, before P2 hasreceived from the ED a request for confirmation of TD (step S21) or arequest to send TD (step S21′), and step S27 may be performed when P2receives the request for confirmation of TD (step S21) or for sending TD(step S21′).

FIGS. 6A and 6B are simplified flowcharts showing an embodiment of thepresent invention provided in connection with the well-known paymentspecifications “EMV Book 3”(http://www.emvco.com/documents/specification/view/EMVv4.1Book3ApplicationSpecification.pdf).

FIG. 6A shows processing steps performed by the communication controllerP1 during an EMV transaction including aspects of the method inaccordance with an embodiment of the present invention. In thisembodiment, the transaction device is used as a payment card compliantwith the EMV specification. The external device ED is assumed to also beEMV-compliant and may be, for example, an EMV terminal.

This embodiment includes the use of a specific data string called “PDOL”(Processing Options Data Object List) that is forwarded to the externaldevice ED by the transaction device to define the structure of thefields present in a command called “Get_Processing_Options” that is tobe sent by the external device to communicate the transaction data. Asdefined in the EMV specification, the PDOL is a list of tags and lengthsof external device-resident data elements required by the transactiondevice to process the Get_Processing_Options command.

The flowchart of FIG. 6A contains processing loops L01, L02, and L03that have been described above in connection with FIG. 3A, as well asprocessing loops L05, L06 and L40.

Loop L05 includes steps S107 and S108. In step S107, P1 receives aSELECT_PPSE command (“Proximity Payment Systems Environment”) from theED. This command indicates that the transaction has begun. In step S108,P1 forwards the SELECT command to P2 to inform P2 that the transactionhas begun.

Loop L06 includes steps S109 and S110. In step S109 P1 receives theSend_PDOL command from P2. In step S110 P1 analyzes and stores the datastructure present in the PDOL field then forwards the PDOL to the ED,for example, via an ODF of the type {x[PDOL]x}.

Loop L40 replaces L04 previously described and contains security stepsaccording to this particular embodiment of the invention. Unlike loopL04, which aims to detect a corruption of the transaction data bymonitoring the outgoing application data OAD forming or comprising suchtransaction data TD, the loop L40 aims at detecting a corruption of thetransaction data by monitoring the incoming application data IAD presentin the Get_Processing_Options command sent by the external device ED.

More particularly, loop L40 includes a step S111 in which P1 receivesthe Get_Processing_Options command from the ED, and a step S112 in whichP1 determines whether the PDOL data structure has been previouslystored. If the PDOL data structure has not been stored, P1 goes to astep S113 where it interrupts the transaction or rejects theGet_Processing_Options command, for instance by indicating to the EDthat the transaction data in the Get_Processing_Options command isinvalid. If the PDOL data structure has been stored, P1 goes to a stepS114 in which it analyzes the data present in the Get_Processing_Optionscommand so as to extract, for example, the amount of the transaction andthe currency involved in the transaction, representing the transactiondata TD. For example, “0x9F02” indicates the amount of the transactionand “0x5F2A” indicates the currency of the transaction. In a step S115,P1 verifies whether agreed transaction data ATD has been stored, i.e.,whether loop L03 including step S05 (Receive ATDR from P2) and step S06(monitor the ID, capture and store ATD) has already been performed. Ifstep S06 has not been performed, P1 goes to step S113 in order tointerrupt the transaction or to reject the Get_Processing_Optionscommand. If transaction data ATD have been stored, P1 goes to a stepS116 in which it verifies whether the transaction data TD (here theamount of money and the currency) is equal to the agreed transactiondata ATD. If the data is not equal, P1 goes to step S113 to interruptthe transaction or to reject the Get_Processing_Options command. If thedata is equal, P1 sends the Get-Processing-Options to P2 so that P2 canfinalize the transaction.

FIG. 6B is a flowchart showing processing steps performed by theapplication processor P2 during the same EMV transaction. Duringpreliminary steps that are not shown in FIG. 6B, the amount and currencyof the transaction—i.e., the transaction data—are communicated verballyor visually to the user by a retailer or a shopkeeper. Then, the useractivates the transaction application program in the transaction mobile,for example, by pressing a specific button on the transaction device orby selecting an option in the general menu displayed on the displaydevice DD. This action causes the processor P2 to activate theapplication program during a step S30. P2 then sends the ATDR command toP1 in a step S31. In a following step S32, P2 prompts the user to enterthe agreed transaction data ATD. Then, in a step S34, P2 monitors theID, then captures and stores data supplied by the ID as agreedtransaction data ATD entered by the user (step S33 takes placesimultaneously with step S06 in FIG. 6A). In a further step S34, P2waits for the Select_PPSE command from the ED that confirms the start ofthe transaction. It is assumed here that the user, after havingactivated the transaction program, has brought the transaction devicecloser to the external device ED so that both are inductively coupledand can exchange data.

When the Select_PPSE command is received, P2 goes to a step S35 in whichit waits for the IAD from the ED through P1. When IAD is received, P2goes to a step S36 in which it processes the IAD and forms outgoingapplication data OAD to the attention of the ED. After step S36, andaccording to the nature of the application data being processed, P2either goes to a step S37 in which it sends the command SEND_DATA [OAD]to P1 (which handles this command in steps S03, S04 in FIG. 6A) or goesto a step S38 in which it sends the command SEND_PDOL to P1 (whichhandles this command in steps S109, S110 in FIG. 6A), then returns tothe wait step S35.

It will clearly appear to those skilled in the art that numerous otherembodiments of the transaction device and methods for securing atransaction can be anticipated. As an example, FIG. 7 shows anotherembodiment of a transaction device 3, which includes the same elementsas described above in connection with FIG. 2, that is, the communicationcontroller P1 and its memory PMEM1, the application processor P2 and itsmemory PMEM2, the input device ID, and the display device DD. Thetransaction device of FIG. 7 differs from transaction device 2 in thatthe input device ID is connected only to the communication controller P1and is linked to the application processor P2 through controller P1.

In this embodiment of the transaction device, a transaction is processedin essentially the same manner as described above in connection withFIGS. 3A to 6B, except that the communication controller P1 isconfigured to forward to the application processor P2 all types of dataentered by the user via the input device ID, for processing by theapplication processor P2, not just the agreed transaction data ATD.Since recent NFC chipset architectures are commonly based on a HostControl Interface (HCl) protocol, according to which the communicationcontroller P1 is configured to route data between the differentprocessors of an NFC chipset, (as proposed by applicant's Europeanpatent application EP 1 855 389), P1 can also be configured to routedata issued by the input device ID to processor P2.

Transaction data that may be protected by embodiments of the presentinvention are generally an amount of money and the correspondingcurrency, but may also be, for example, a number of “units” or “tokens”having a monetary value, a quantity of goods ordered during thetransaction, and generally speaking any essential data involved in atransaction and subject to the agreement of the user.

Finally, although embodiments of the present invention were initiallyconceived and developed for portable devices having an NFC communicationcontroller, it will be apparent to those skilled in the art that thetransaction methods that have been described are applicable to othertransaction devices using different methods of communicating withexternal devices and implementing different standards of communication.

It will be appreciated by those skilled in the art that changes could bemade to the embodiments described above without departing from the broadinventive concept thereof. It is understood, therefore, that thisinvention is not limited to the particular embodiments disclosed, but itis intended to cover modifications within the spirit and scope of thepresent invention as defined by the appended claims.

I claim:
 1. A transaction device for securing a transaction comprising:an NFC controller configured to receive, via a contactless NFCinterface, data related to the transaction from an external device; acommunication interface configured to receive an application program forthe transaction device; an application processor coupled to the NFCcontroller and configured to process the application program; a displaycoupled to the application processor and configured to displaytransaction information; and a user input device linked to the NFCcontroller and configured to receive a user acknowledgement of thetransaction, and wherein the NFC controller is further configured totransmit, via the contactless NFC interface, a transaction agreement ofthe transaction to the external device in response to the useracknowledgement from the user input device, without the useracknowledgement and the transaction agreement being routed through theapplication processor.
 2. The transaction device of claim 1 wherein theuser acknowledgement is a personal code.
 3. The transaction device ofclaim 1 wherein the user input device is a biometric input.
 4. Thetransaction device of claim 1 wherein the communication interface isWi-Fi.
 5. The transaction device of claim 1 wherein the communicationinterface is mobile phone communication.
 6. A method performed by atransaction device for securing a transaction comprising: receiving, viaan NFC controller and a contactless NFC interface, data related to thetransaction from an external device; receiving, via a communicationinterface, an application program for the transaction device;processing, via an application processor coupled to the NFC controller,the application program; displaying, via a display coupled to theapplication processor, transaction information; receiving, via a userinput device linked to the NFC controller, a user acknowledgement of thetransaction; and transmitting, via the NFC controller and thecontactless NFC interface, a transaction agreement of the transaction tothe external device in response to the user acknowledgement from theuser input device, without the user acknowledgement and the transactionagreement being routed through the application processor.
 7. The methodof claim 6 wherein the user acknowledgement is a personal code.
 8. Themethod of claim 6 wherein the user input device is a biometric input. 9.The method of claim 6 wherein the communication interface is Wi-Fi. 10.The method of claim 6 wherein the communication interface is mobilephone communication.